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About This Manual 


Purpose of this Manual 


This manual presents an overview of SQL Connector on client (first tier), data broker 
(second tier) and data driver (third tier) operating systems. Examples are provided to 
illustrate how soL Connector can be used in a variety of environments. 


Intended Audience 


This document is intended for end users, programmers and system administrators who 
will be using soL Connector. A working knowledge of J ava, ODBC, J DBC, database 
systems, Windows and Netware operating systems and networking is suggested for 
using soL Connector. 


Structure of this Manual 


This manual consists of chapters that provide an overview of SQL Connector, a 
description of its architecture and a discussion of Windows environments for using SQL 
Connector. 


Associated Documents 


The document set contains these manuals: 
* sol Connector Overview 
e soL Connector Installation Guide 
e soL Connector Administration Guide 
e sor Connector SQL Grammar Manual 
e soL Connector ODBC Programmer's Guide 
e soL Connector | DBC Programmer's Guide 


Operating System Conventions 


When there are differences in commands, examples, or syntax between operating 
systems, the following abbreviations are used: 


Abbreviation Meaning 
NetWare the Novell NetWare operating system 
Windows the Microsoft Windows 95/98/NT operating systems 





SQL Connector Overview 





Table of Contents 


About This Manual ..... 2.00000 ee eee een ee eee V-3 
Table of Contents ...0ccoccoccocoo ee V-4 
l.Introductioni iaa ds V-5 
1.1 Overview..................................... V-5 

12 Components................................... V-5 

1.3 Architecture ................................... V-6 

1.3.1 Three Tier Application (Intranet or Internet) ...... V-7 

1.3.2 Two Tier Application (Two Data Sources). ........ V-7 

1.3.3 Architecture Diagram ...................... V-8 

2 ArChitCctures 24 Fs wale i V-9 
2.1 Client Components .............................. V-9 

2.1.1. ODBC Driver à mi valid Aw AOE ea ee aoa ie wea à V-9 

2.1.2 JDBC Driver............................. V-9 

2.2 Data Broker Components.......................... V-9 

2.2.1 Data Sources............................ V-9 

2.2.2 Data Source Administrator. ................. v-10 

2.2.3 Data Request Broker...................... v-10 

2.3 Data Driver Components ......................... v-12 


2.3.1 Direct Connection to a Database Vendor Library. . . V-12 
2.3.2 Network Connection to a Database Vendor Library . V-12 


3 USA A A ee ee ee V-13 
3.1. OVEMVIEW:. à; 4 sas e E i V-13 

3.2 Database Administration ......................... V-13 
3.2.1 Installation ............................ V-13 

3.2.2 Configuration........................... V-13 

3:2:3 . Testi: ipa 24 me renier ee Hesse V-13 

3.3 Application Development . ooo... o... V-14 
3.3.1 Programming........................... V-14 

3:3:2 Testing : ss e dia ae Sake Sages sun ae V-14 

3.4. SUMIMAFY pi a AA de de Ra Ho © ae V-14 





SQL Connector Overview 





1 
A ea) 
Introduction 





1.1 Overview 


SQL Connector is a Data Request Broker that supports a multipletier, multiple 
database enterprise environment for connecting ODBC and J DBC applications 
between client computer systems and databases on Netware or Windows NT. The 
Data Request Broker runs on the middle-tier (between the client systems and database 
servers) and supports a methodology known as Enterprise Data Access (EDA). EDA 
has the following features: 


e All databases can be accessed Using one middleware connection from the client system, 
as opposed to one connection per database. 


e All data can be accessed using a standard SQL grammar and set of datatypes, as 
opposed to vendor-specific SQL and datatypes. 


Applications that connect to soL Connector are database independent. These 
applications connect to the Data Broker which connects to the physical database. 
Applications are thus isolated from database specific variations, such as alternate 
forms of SQL grammar and alternate datatypes. ANSI-92 standard SQL statements 
can be used (Such aS SELECT..., UPDATE..., etc.), without regard for the database 
source. ANSI standard datatypes (such as CHAR, INTEGER, TIMESTAMP) can be used, 
without regard for database specific datatypes. 
































From the client viewpoint, SQL Connector presents enterprise physical databases as 
uniform standard ANSI-92 SQL Data Sources. Only one connection is required from 
the client system to soL Connector, which then connects to the physical databases. 


Please see the Installation Guide for additional information about supported 
databases and platforms. 


1.2 Components 


SQL Connector includes Client, Data Broker and Data Driver components. These 
components can reside on the same or different computer systems within a network. 
The Client components support the connection of soL Connector to end-user or web- 
based applications, or application development tools, that use OBDC or J DBC. The 
Data Broker components support client connectivity over a network, and query 
parsing, optimization and distribution. Thereis alsoa Data Broker component for 
definining and managing Data Sources. The Data Driver components support 
connectivity to physical databases. The components can be summarized in the 
following table: 








Component Name Component F unctionality 














Client Components 
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Component Name 


Component F unctionality 








soL C-ODBC 


Microsoft® ODBC API 





SQL C-J DBC 


J avaSoft™ J ava” SQL classes 





Data Broker Components 





SQL C-DSA 


Data Source Administrator 





SQL C-DRB 





Data Request Broker 





Data Driver Components (local or remote to the Data Broker) 





SQL C-ORA-DD 


Oracle® Database Connection 





soL C-ODBC-DD 








Microsoft ODBC™ Database Connection 








1.3 Architecture 


The soL Connector architecture includes the Client, Data Broker and Data Driver 


components listed in the above table. The architecture is designed for maximum 
flexibility in meeting the needs of enterprise wide application development and 


deployment. The components have been modularized so that they can be installed on 
multiple tiers within an enterprise network. The following examples illustrate several 
possible configurations. The examples show how SQL queries from a client can be 

distributed by the Data Broker to multiple databases. 
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1.3.1 Three Tier Application (Intranet or Internet) 


A three tier application 


example is a J ava applet SQL Connector Browser Example 


running on a Windows a | AWA BROWSER APPLET | 
browser (client) that uses a “= A 

soL C-J DBC to access a Cana 

NetWare Data Broker. The Network eee = E 
Data Broker accesses an NA A AAA 
Orade database running on le A o 
the same system (with a Data Broker |!" = ee | 


local data driver) and uses iui | 
the network to access an Leña Deve [RE] pai 
MS-SQL Server database = Pa 


i cart 
on a Windows NT system rs 
(using Remote Data Driver sr aa feed 
on NT). Data Driver | snc | Er 


|g | Database Network 


1.3.2 Two Tier Application (Two Data Sources) 


A two tier application 











example is a Visual Basic SQL Connector Visual Basic Example 
application runningon a VISUAL BASIC 
Windows system that uses Chant APPLICATION 
SQL C-ODBC to access a System = 
Netware Data Broker. The Leu CDE | 
Netware Data Broker can be Newark | A 
used to retrieve from both Ma = = > 
Access and MS-SQL Server — = = sos 
(using Remote Data Drivers hhh Ee nes 
on NT). tane 

Windows NT | sac 

Remote CDR = 


Data Driver 


I 
i AS ll 
SE | Dabas | etak 
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1.3.3 Architecture Diagram 
The complete soL Connector component architecture is shown below: 


SQL Connector Components 
Windows 

















Client Dictionary Manager and SQL ODBC Driver JDBC Driver 
System ¿qu C- MGR and sol C- SQ ag. C- DOC #oL C- JDBC 
Network 





Dictionary - soLC-DICI 
Data Request Broker - toL C -ORA 





Netware 







Data Broker 


Local 
Data Driver 


Network 


Windows NT 
Remote 
Data 
Driver 


ACCESS 


The Client components (ODBC and J DBC drivers) can be used on both Windows 
(client) and Netware (broker) systems. Uses on Windows systems would include 
connecting to third party application development tools such as Microsoft Visual Basic 
(OBDC) and Symantec Visual Cafe (| DBC). Uses on Netware systems would include 
connecting to the Netscape Enterprise Server (ODBC) or IBM WebSphere Application 
Server (J DBC). 

Also, the Data Drivers can be used on the same node as the Data Broker (local) or ona 
different node (remote), depending on the location of the physical database. 






sE | Database i Network 
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Architecture 





2.1 Client Components 


2.1.1 ODBC Driver 


ODBC (Open Database Connectivity) is an API (Application Programming Interface) 
developed by Microsoft. ODBC is Microsoft's implementation of the X/Open SQL CLI 
(Call Level Interface) that defines how client/server interactions are implemented for 
database applications. ODBC also supports the SQL grammar and syntax specified in 
the ANSI SQL-92 standard. 


ODBC was developed to provide vendor neutral access to data sources from a client 
application. With ODBC, a client application is not restricted to any one vendor's 
proprietary interface, and the client application can connect to any ODBC-compliant 
data source. 


SQL C-ODBC is a Microsoft compliant implementation of the ODBC API (version 2.5). 
As such, any client application or application development environment can connect to 
SQL C-ODBC. soL C-ODBC provides an enhanced ODBC SQL Grammar that can 
access database tables from multiple networked databases. 


2.1.2 JDBC Driver 


J DBC (J ava Database Connectivity) is a vendor neutral API developed by J avaSoft. 
The interface is very similar in concept to the Microsoft ODBC API and provides J ava 
programmers with a uniform database interface to a wide range of relational 
databases. J DBC is a standard part of J ava and is included in J DK (J ava 
Development Kit) 1.1. Like ODBC, a J ava J DBC application is not restricted to any 
one vendor’s proprietary interface, and the] ava application can connect to any J DBC- 
compliant data source. 


SQL C-J DBC is a 100%) ava J DBC compliant implementation of the] DBC API (type 
IV, version 1.1). Any J ava application, applet, or application development 
environment can connect to soL C-] DBC. soL C-J DBC provides a database 
independent SQL grammar that can access database tables from multiple databases. 


2.2 Data Broker Components 


2.2.1 Data Sources 


SQL Connector supports access to multiple physical databases by using Data Sources, 
which are defined on the same node as the soL Connector Data Broker. The Data 
Sources have table entries that point to physical database tables or views on the same 
node or other nodes elsewhere in the network. Database views are very useful when 
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the application only needs a subset of fields in a table, or the application requires 
frequent joins of multiple database tables. 


A client application built using soL Connector is only aware of the database tables 
defined by a Data Source and not the physical source of the data. The physical 
database source can be changed, for example, from MS Access to Oracle, or from Oracle 
to MS-SQL, with no change required in the application. 


SQL Connector Data Sources support client applications which are database 
independent. Even though ODBC and J DBC provide vendor neutral programming 
interfaces, these interfaces themselves are not database independent. For example, 
some database vendors do not support ANSI SQL datatypes for decimal numbers. 
Consequently, applications built with vendor supplied interfaces must be aware of 
which datatypes are supported. In contrast, soL Connector is database independent. 
If an ANSI SQL datatype is not supported by the physical database, the datatype is 
emulated by the Data Source and mapped to an appropriate physical database type. 


2.2.2 Data Source Administrator 


The soL Connector Data Source Administrator (soL C-DSA) is a web browser 
application for creating and maintaining soL Connector Data Sources and for 
importing physical database table information. The soL Connector Data Source 
Administrator primary web page is shown below: 


SOL Connector for NetWare 


Administer Data Sources 


Select a current Data Source and choose an action 


niche arrast 
Belhadi 





2.2.3 Data Request Broker 


SQL Connector contains a Data Request Broker (DRB) which includes a sophisticated 
SQL processor, optimizer and distributor. The SQL processor converts ANSI standard 
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SQL into database vendor specific SQL, regardless of the database. TheSQL processor 
supports full read/ write capability for all database connections. 


Structured Query Language (SQL) is a well-defined ANSI (American National 
Standards Institute) standard language for database access. Database vendors strive 
to support the grammar and syntax of the SQL language, but inevitably change the 
implementation to support database specific features. The SQL processor is based on 
the ANSI SQL-92 standard and is database independent. Database independent SQL 
eliminates the need to learn each vendor’s dialect of SQL, not all of which are SQL-92 
compatible. The SQL processor also provides enhanced datatype support that may be 
missing from a vendor-specific database. See the SQL Grammar Manual for 
additional information. 


SQL processing begins by decomposing an SQL statement (which may have embedded 
subqueries) into its constituent parts: 


e data query statements (read data) 


. select 
e data manipulation statements (write data) 
. update 
. insert 
. delete 


Data queries are processed first, since the results may be needed for a data 
manipulation statement. For example, a statement like: 
update emp set bday = (select bday from personnel wher mpno = 1234) 


would requirethe select statement to be processed first, since the result is needed for 
the update statement. 





Data Query Processing 


sQL C-DRB can decompose, rewrite and distribute data queries as close to the data 
source as possible. soL C-DRB also performs query pushdown and query 
optimization. 


Query Decomposition and Rewrite 


An incoming query from a client application that is using ANSI-standard SQL 
(independent of the database) must be rewritten using vendor-specific SQL before 
being sent from the broker to the database. The rewrite process also analyzes the 
syntax for built-in SQL functions (such as sum, AVG, MIN, and max) that may or may not 
be supported by the database vendor's SQL. Ifthe function is not supported by the 
vendor, than a vendor-supported function is substituted if one is available. If there is 
no vendor-equivalent function, then a rewritten query (without the function) is sent to 
the database, and the function will be performed by the broker when the rows are 
returned. 


As example of using vendor specific functions, consider the conversion of a date string, 
such as a statement like WHERE EMP_DATE > "07/08/99". If the database is Oracle, 
then the broker will use the Oracle ro_paTE function when the query is rewritten. If 
the database is ODBC, then the broker will use the ODBC convert function. 


























Query Pushdown 


Decomposition of a query also leads to decisions regarding how much of the query can 
be pushed down into the physical database. Examples of pushdown operations are 
aggregates, join Clauses, where Clauses and order by Clauses. SQL C-DRB will 
determine how much of the query can be sent directly to the database and how much 
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must be processed by soL C-DRB. soL C-DRB attempts to push as much processing 
down to the underlying database as possible to maximize the overall performance. 


Pushdown processing reduces network traffic by reducing data flow across the 
network. For example, the sum function is pushed down into the database if the 
function is supported. Only the result is returned across the network. If the 
Summation was not pushed down, then all of the field values would be returned across 
the interface, which would result in increased network traffic. 

Query Optimization 

SQL C-DRB has the capability to rewrite a database query based on keys and indexes 
in the physical database. soL C-DRB bases its decisions on the cardinality and 
selectivity of the tables involved in the query. This information determines the order 
and sequence of interactions with the tables in the query. The primary goal of the 
query optimization is to reduce the bandwidth requirements between soL Connector 
and the underlying physical databases. 


2.3 Data Driver Components 


ThesaL Connector Data Broker connects to physical databases (local Oracle or Remote 
ODBC) using the soL Connector Data Driver components. There is a Data Driver 
component for each supported database. The Database Drivers generally connect to 
the physical databases in the following ways: 

e soL Connector direct connection to a vendor supplied connectivity library 


e sol Connector network connection to a vendor supplied connectivity library 


Direct Connection to a Database Vendor Library 


The most direct form of connection is to use the database vendor supplied connectivity 
library running on the same Netware system as thesoL Connector Data Broker and 
Data Driver components. The vendor library will then connect to the vendor database, 
which is executing on a database server that is the same Netware system or another 
computer system. 


The following table shows the soL Connector Data Drivers and the respective vendor 
libraries: 





Database Component | Component Name Vendor Library 








SQL C-ORA-DD Data Driver for Oracle OCI 

















A vendor library connects to the physical database if it runs on the same computer 
system as the soL C-DRB. 


2.3.2 Network Connection to a Database Vendor Library 


The Data Broker can connect across the network to a SQL Connector ODBC Data 
Driver running on a remote Windows NT system. Theremote ODBC Data Driver then 
connects to the vendor supplied connectivity library running on the same remote 
system (Microsoft Access, Microsoft SQL Server, or Oracle). 
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Usage 





3.1 Overview 


The steps required to usesoL Connector will vary from site to site and within systems 
at a given site. These steps include the following: 


e DBA (Database Administrator) activities 
e Installation 
e Configuration 
e Testing 
e Application Development Activities 
e Programming 
e Testing 


3.2 Database Administration 


3.2.1 Installation 


SQL Connector installation should be planned around which computer systems are 
client systems, which systems are application or web servers and which systems are 
database servers. Use of soL Connector may require third party software such as 
ODBC driver managers, J ava development kits, database vendor connectivity 
software and database server software. 


3.2.2 Configuration 


SQL Connector is configured using the client component soL C-DSA. The Data Source 
Administrator runs on a web browser and accesses Data Sources on a Data Broker 
system. The Data Sources then access data from physical databases. 


SQL C-DSA is used to create the Data Sources and to import metadata information 
from physical databases on database servers. 


SQL statements executed by the Netscape Server "dbadmin" facility may be used to 
query the Data Source tables (and hence the physical database tables) using ANSI 
standard SQL statements. Thus the Data Source can be tested before a client 
application is available. 


3.2.3 Testing 


There are sample ODBC and J DBC programs and a database that are supplied for 
testing purposes. These programs can test a database connection and retrieve joined 
data (between departments and employees). The Data Source and sample programs 
are supplied with source code (SQL, C and J ava) to provide a starting point for 
programmers who will be developing soL Connector applications. 
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3.3 Application Development 


3.3.1 Programming 


Once a Data Source and data access has been tested, application development can 
begin. Application development typically uses one of the following environments: 


e Application development tools that support ODBC, for example: 


Microsoft Access 
Microsoft Visual Basic 
Powersoft PowerBuilder 
Borland Delphi 
Netware Data Objects 
e Application development tools that support J DBC, for example: 
Borland J Builder 
Powersoft Power] 
Symantec Visual Cafe 
Netscape] avaScript 
IBM WebSphere 
e Programming languages that call the ODBC API or J ava SQL classes. 
e Microsoft Visual C++ 
e Watcom C++ 
e Microsoft Visual J ++ 


Regardless of the choice of application development environments, the use of SQL 
Connector is transparent because of the ODBC and J DBC standards. 


3.3.2 Testing 


The application tools and programming languages have test capabilities that can be 
utilitized during the development process. SQL statements can be sent to the Data 
Request Broker and analyzed in isolation from an application. These SQL statements 
can be tested for syntax, performance and efficiency. Database timing and database 
traces can be used to look for performance bottlenecks such as joins using non-unique 
indexes, sequential searches through large tables, and failure to push down SQL 
statements from the application to the physical database. 


3.4 Summary 


SQL Connector is a data access Data Request Broker environment that provides a 

multiple-tier, multiple-database enterprise environment for connecting ODBC and 

J DBC compliant applications to multiple database sources. 

e sat Connector includes client components for connecting to ODBC and] DBC 
environments and for maintenance and testing of soL Connector Data Sources. 

e sol Connector includes Data Broker components for query parsing, optimizing and 
distribution, even among multiple databases. 


e soL Connector includes Data Driver components for connecting to vendor 
databases in the absence of a vendor connectivity library and provides additional 
connectivity not supplied by database vendors. 
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